iT邦幫忙

2025 iThome 鐵人賽

DAY 4
0
生成式 AI

30 天與 AI 同事打造系統的求生實錄系列 第 4

【Day 4】和 AI 對話,不說清楚真的會出事

  • 分享至 

  • xImage
  •  

今天是鐵人賽的第四天,目標是請AI同事規劃後端的架構。
討論了一些要使用的設計方法跟PYTHON環境的放置
還有功能建構的順序~
結果最後差點因為 "那個" 指令,直接把我這幾天的進度毀了
跟AI共識,最好每完成一部分就檢視一下成果,不然很可能他直接陽奉陰違XD

以下為今天的研究流程


老樣子第一步都是請AI同事了解現況

我給AI的指令:

@ai_context.md @README.md @軟體核心架構規劃.md @功能需求總覽.md   了解目前現況

等他了解了之後,在放開讓AI同事建置後端之前,我想請他先規劃功能建置的順序,因為不先規劃好,可能你在建置A功能時,因為需要B功能的資料而出錯,雖然可以透過假的測試資料先測試單一功能,但之前在測試時,AI同事不太能理解這個意思,導致他為了修因為沒有資料而出現的錯誤,亂試一通。
這次參考以前的經驗,我打算先讓他排一下建置順序,減少這類錯誤的發生。
我給AI的指令:

@agents/engineering/backend-architect.md 請幫我規劃後端功能建置的順序,如果功能需要依賴其他功能的需等依賴的功能做好再建置,例如任務功能通常是依賴在某個專案底下,那就需要把專案功能先建置好。

AI同事人很NICE,他幫我把功能建置順序分成五個階段,下面列出標題:

  • 階段一:基礎架構與核心使用者管理
  • 階段二:核心專案與任務管理
  • 階段三:輔助功能與數據準備
  • 階段四:AI服務與外部整合
  • 階段五:系統優化與管理功能

目前以我的角度看起來他規劃的很適合,我就沒繼續請他調整,不過這時突然想到,建構程式有很多設計方法如SOLID、MVC等,我想說先請他考慮我的應用,適合哪種方法,因此我跟AI同事再次討論。
我給AI的指令:

根據你對我的應用的了解,你覺得我的應用適合哪種設計方法? SOLID、Design Patterns、FP、MVC...等,或其他設計方法,幫我分析後比較優缺 

結果他建議我把方法結合起來,以下是AI同事的原文:

綜合來看,TaskWhisper 最適合的設計方法是:以 SOLID 原則為基礎,結合領域驅動設計來構建強健的後端業務模型,並在前後端開發中靈活運用設計模式。前端則採用 MVVM模式。同時,要持續應對微服務架構帶來的複雜性挑戰。

但我有點擔心這樣會不會太亂整個衝突,但AI同事跟我掛保證這樣做一定行,那我就尊重AI同事的決定。

接下來還有一個隱憂,我之前請AI幫我用PYTHON建構程式時,PYTHON的環境其實是蠻混亂的,所以我這次想指定他幫我建一個隔離環境在後端資料夾來避免同樣事情發生。
我給AI的指令:

我還有一個問題,我後端有一個部分是使用PYTHON,但我希望他是獨立環境,我想將PYTHON環境直接放在後端資料夾內,可以實行嗎? 實行的方法與優缺 

AI同事了解後提出了使用VENV去建構PYTHON的虛擬環境,看起來是很符合我的需求。
到此,AI同事已經了解並掌握我想建構的應用,接下來就可以請他開始幫我建構應用啦
我給AI的指令:

好的,目前所有我想討論的地方都討論完畢,請你先將我們討論的內容更新到@ai_context.md @README.md後,開始建構後端 

然後...然後就出事啦XDDD

我是想讓他把討論的資訊新增到ai_context.md、README.md,結果可能我用詞不夠精準,他直接把我裡面的內容全蓋掉了XD
這個故事告訴我們,話不要講得太簡略,而且最好做版本控制XD

接下來我用了幾個恢復的指令,但沒有成功,後來我發現因為我是打檔名而不是用 @ 去指定檔案所以失敗了
我下的恢復指定:

之前的更新README.md不是要你覆蓋掉舊的資料,而是請你將我們討論的內容新增上去
@README.md 沒有恢復成功

第一個指令失敗了,因此我補充了第二個指令,他就正常復原了,嚇了我一跳XD


因為中間穿插了不少恢復的手忙腳亂XD,所以我請AI同事先整理今天討論的資訊。
AI同事的回覆:

好的,這就為您整理今天討論的內容:

  今天我們主要討論了 TaskWhisper 專案的以下幾個方面:

   1. 專案現況理解:
       * 我閱讀了 README.md、ai_context.md、軟體核心架構規劃.md 和 功能需求總覽.md,並為您總結了 TaskWhisper的專案目標、核心功能、技術選型和系統架構。

   2. 後端功能建置順序規劃:
       * 我根據功能間的依賴性,為您規劃了後端功能的建置順序,分為基礎架構與使用者管理、核心專案與任務管理、輔助功能與數據準備、AI 服務與外部整合、以及系統優化與管理功能等階段。

   3. 設計方法討論:
       * 我們討論了 SOLID 原則、設計模式、領域驅動設計 (DDD)、MVVM 模式和微服務架構等設計方法。
       * 我分析了這些方法的優缺點,並建議 TaskWhisper 專案應綜合運用這些方法:以 SOLID 為基礎,結合 DDD構建後端業務模型,靈活運用設計模式,前端採用 MVVM,並持續應對微服務架構的挑戰。
       * 我們也澄清了這些方法是互補而非矛盾的,它們在不同抽象層次上共同作用。

   4. Python 後端獨立環境:
       * 我們討論了將 Python 獨立環境 (虛擬環境 venv) 直接放在後端資料夾內的可行性。
       * 我解釋了使用 venv 的實行方法,並分析了其優點(如依賴隔離、環境重現性、系統環境整潔、專案管理簡化、可攜性)和潛在的缺點。

   5. 操作與恢復:
       * 我嘗試根據討論內容更新 README.md,並建立後端資料夾、虛擬環境及 requirements.txt 檔案。
       * 在安裝依賴時,psycopg2-binary 出現安裝錯誤。
       * 應您的要求,我已將所有修改過的檔案和新建立的資料夾恢復到討論前的狀態。

  以上是今天討論的重點摘要。

看起來還是整理得不錯,這次我再次下指令去更新資訊,不過這次講得更清楚一點。
我給AI的指令:

請幫我把1-4的討論的內容資訊,更新到 @ai_context.md @README.md上,請將資訊放在適合的位置,以利之後好了解應用現況 

這次,他就照著我的意思幫我把資訊放在適合的位置了~


今天AI同事開始偷偷鬧了一下,還好都還在可控範圍,基本上只要你的CLI不要被關掉,不要經過太久,他都還是有足夠的資訊去恢復檔案的,這也是我覺得目前跟AI同事還是協做比較好,不然他一個理解錯誤,你又沒注意直接存檔了,很容易前面的工作就打水飄了~


上一篇
【Day 3】為了不重寫前端,我現在就要跟 AI 講清楚
下一篇
【Day 5】AI同事是幫手不是主導,錯誤別跟著它硬上!
系列文
30 天與 AI 同事打造系統的求生實錄30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言